Companies and other entities that deploy and use computer financials applications use services to process payments from their own customers. These services are commonly known as lockbox services. Lockbox services allow business entities to take advantage of economies of scale available at financial institutions such as banks. The business entity takes advantage of these economies of scale by consolidating their payment processing with that of the financial institution's other clients.
Some conventional lockbox technologies use a row-by-row (e.g., payment line-by-payment line) processing paradigm. However, a row-by-row processing paradigm can be difficult to maintain. Further, logic based on the summarization of payments can be difficult to implement with this conventional method. However, financials applications developers may for example, want to create trade deductions for a given invoice based on the final sum of all payment lines for the invoice, which could be troublesome to implement conventionally.
Typically, most lockbox files are created by human data-entry clerks. Thus, lockbox files are prone to typographical and other related errors. One significant limitation of lockbox solutions in general is the incapability of the lockbox solutions to handle user error. Also, to participate in lockbox remittance handling, a business entity typically may request that its customers mark their remittances with a unique identifier or another identifying feature, such as an identifying number or other such marker. Sometimes, the marker is be placed in a particular location on the remittance.
How customers respond to a billing entity's request for marking their remittances with an identifying number depends on several factors. One such factor is that customers cooperatively respond to the entity's request. Where customers willingly provide the requested identifying marker, other issues can arise that may hamper the lockbox remittance handling efforts. For instance, the marker may not be placed in the requested or most ideal location: customers may place the identifier based on their own whims and judgment, which can be error prone.
In order to utilize and bolster their lockbox remittance handling efforts, business entities and business financials applications developers have engaged in on-going efforts to work around these issues. Conventional efforts to correctly (e.g., accurately and precisely) match a remittance to the transaction it is intended to pay have generally aimed at attempting to render an exact match between the identifying number provided by the customer to a variety of the possible identifying numbers or other identifiers associated with a transaction.
Conventionally, the amount of a payment and the identity of the customer remitting it are also typically taken into consideration when matching the remittance to a transaction. In conventional approaches to correctly match a remittance to the transaction it is intended to pay, users also typically have to provide an order of significance of the types of identifying numbers to be matched. For instance, one exemplary possible user selected hierarchy can be to match against invoice numbers first; if that fails, match against sales order numbers, and so on.
These conventional workarounds however require precise entry of the identifying information, which as discussed above is prone to error. Conventional techniques also tend to discard possible matches because of inflexibility inherent in the selection of ordering hierarchy, such as what types identification numbers are tried. For instance, customers may sometimes remit amounts other than the invoiced amount. Thus, inflexible conventional techniques may discard matches because the payment amounts are not equal to the amount due remaining on the transaction.
The inability to accurately and precisely match a remittance with its correct corresponding transaction can be costly. A business entity may forestall applying the remittances until the correct match is made. Delay in applying the remittances can result in concomitant delay in availability of funds. Where a match is not returned on the basis of information supplied with the remittance, direct human intervention can be required in the form of research conducted, which can be painstaking, in order to match the remittance and transaction. Costs of such research can be significant.
Thus, conventional approaches matching remittances to transactions that are undertaken by business entities can be inadequate. Their processing paradigm can be difficult to maintain and can deter use of logic based on the summarization of payments. They are prone error. Identifiers used to match remittances to particular transactions may be misplaced by customers and then overlooked by the receiving entity. Conventional workarounds are constrained by inflexibility, such that they discard or overlook information that can result in proper matches between the remittance and the transactions to which they should be matched.